1
2
De volgende
Nee.
De JSON zijn alleen gegevens, en als u een opmerking opneemt, zijn het ook gegevens.
U zou een aangewezen gegevenselement kunnen hebben met de naam "_comment" (of zoiets) dat moet worden genegeerd door apps die de JSON-gegevens gebruiken.
Het is waarschijnlijk beter om de opmerking te hebben in de processen die de JSON genereren / ontvangen, omdat ze van tevoren moeten weten wat de JSON-gegevens zullen zijn, of in ieder geval de structuur ervan.
Maar als u besluit om:
{
"_comment": "commentaartekst komt hier ...",
"woordenlijst": {
"title": "voorbeeldwoordenlijst",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879: 1986",
"GlossDef": {
"para": "Een meta-opmaaktaal, gebruikt om opmaaktalen zoals DocBook te maken.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
|
Nee, opmerkingen van het formulier //… of / *… * / zijn niet toegestaan in JSON. Dit antwoord is gebaseerd op:
https://www.json.org
RFC 4627:
Het application / json-mediatype voor JavaScript Object Notation (JSON)
RFC 8259 The JavaScript Object Notation (JSON) Data Interchange Format (vervangt RFC's 4627, 7158, 7159)
|
Voeg eventueel commentaar toe; strip ze uit met een minifier voordat ze worden geparseerd of verzonden.
Ik heb zojuist JSON.minify () uitgebracht, dat opmerkingen en witruimte uit een blok JSON verwijdert en het een geldige JSON maakt die kan worden geparseerd. Dus je zou het kunnen gebruiken als:
JSON.parse (JSON.minify (my_str));
Toen ik het uitbracht, kreeg ik een enorme terugslag van mensen die het zelfs niet eens waren met het idee ervan, dus besloot ik een uitgebreide blogpost te schrijven over waarom opmerkingen zinvol zijn in JSON. Het bevat deze opmerkelijke opmerking van de maker van JSON:
Stel dat u JSON gebruikt om configuratiebestanden te bewaren die u wilt annoteren. Ga je gang en voeg alle opmerkingen in die je leuk vindt. Leid het vervolgens door JSMin voordat u het aan uw JSON-parser overhandigt. - Douglas Crockford, 2012
Hopelijk is dat nuttig voor degenen die het niet eens zijn met waarom JSON.minify () nuttig zou kunnen zijn.
|
Opmerkingen zijn standaard verwijderd uit JSON.
Ik heb opmerkingen uit JSON verwijderd omdat ik zag dat mensen ze gebruikten om ontledingsrichtlijnen vast te houden, een praktijk die de interoperabiliteit zou hebben vernietigd. Ik weet dat het gebrek aan opmerkingen sommige mensen verdrietig maakt, maar dat zou niet moeten.
Stel dat u JSON gebruikt om configuratiebestanden te bewaren, die u wilt annoteren. Ga je gang en voeg alle opmerkingen in die je leuk vindt. Leid het vervolgens door JSMin voordat u het aan uw JSON-parser overhandigt.
Bron: openbare verklaring van Douglas Crockford over G +
|
JSON ondersteunt geen opmerkingen. Het was ook nooit bedoeld om te worden gebruikt voor configuratiebestanden waar commentaar nodig zou zijn.
Hjson is een configuratiebestandsformaat voor mensen. Ontspannen syntaxis, minder fouten, meer opmerkingen.
Zie hjson.github.io voor JavaScript-, Java-, Python-, PHP-, Rust-, Go-, Ruby-, C ++ - en C # -bibliotheken.
|
DISCLAIMER: UW GARANTIE IS ONGELDIG
Zoals opgemerkt, maakt deze hack gebruik van de implementatie van de specificatie. Niet alle JSON-parsers zullen dit soort JSON begrijpen. Vooral streaming-parsers zullen stikken.
Het is een interessante nieuwsgierigheid, maar je zou het eigenlijk helemaal nergens voor moeten gebruiken. Hieronder staat het oorspronkelijke antwoord.
Ik heb een kleine hack gevonden waarmee je opmerkingen in een JSON-bestand kunt plaatsen die het parseren niet beïnvloeden, of de gegevens die op enigerlei wijze worden weergegeven, wijzigen.
Het lijkt erop dat u bij het letterlijk declareren van een object twee waarden met dezelfde sleutel kunt specificeren, en de laatste krijgt voorrang. Geloof het of niet, het blijkt dat JSON-parsers op dezelfde manier werken. We kunnen dit dus gebruiken om opmerkingen in de bron-JSON te maken die niet aanwezig zullen zijn in een geparseerde objectweergave.
({a: 1, a: 2});
// => Object {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Length;
// => 1
Als we deze techniek toepassen, kan uw becommentarieerde JSON-bestand er als volgt uitzien:
{
"api_host": "De hostnaam van uw API-server. U kunt ook de poort specificeren.",
"api_host": "hodorhodor.com",
"retry_interval": "Het interval in seconden tussen het opnieuw proberen van mislukte API-aanroepen",
"retry_interval": 10,
"auth_token": "Het authenticatietoken. Het is beschikbaar in uw ontwikkelaarsdashboard onder 'Instellingen'",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "Een array met mijn favoriete nummers aller tijden",
"favourite_numbers": [19, 13, 53]
}
De bovenstaande code is een geldige JSON. Als je het ontleedt, krijg je een object als dit:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favourite_numbers": [19,13,53]
}
Wat betekent dat er geen spoor is van de opmerkingen en dat ze geen rare bijwerkingen zullen hebben.
Veel plezier met hacken!
|
Overweeg om YAML te gebruiken. Het is bijna een superset van JSON (vrijwel alle geldige JSON is geldige YAML) en het staat commentaar toe.
|
U kunt het niet. Dat is tenminste mijn ervaring na een snelle blik op json.org.
JSON heeft zijn syntaxisgevisualiseerd op die pagina. Er is geen enkele opmerking over opmerkingen.
|
Opmerkingen zijn geen officiële standaard, hoewel sommige parsers opmerkingen in C ++ - stijl ondersteunen. Een die ik gebruik is JsonCpp. In de voorbeelden is er deze:
// Configuratie-opties
{
// Standaardcodering voor tekst
"encoding": "UTF-8",
// Plug-ins geladen bij het opstarten
"plug-ins": [
"Python",
"c ++",
"robijn"
],
// Inspringgrootte van tabblad
"indent": {"length": 3, "use_space": true}
}
jsonlint valideert dit niet. Opmerkingen zijn dus een parserspecifieke extensie en niet standaard.
Een andere parser is JSON5.
Een alternatief voor JSON TOML.
Een ander alternatief is jsonc.
De nieuwste versie van nlohmann / json heeft optionele ondersteuning voor het negeren van opmerkingen over het parseren.
|
U moet in plaats daarvan een JSON-schema schrijven. JSON-schema is momenteel een voorgestelde internetconceptspecificatie. Naast documentatie kan het schema ook worden gebruikt voor het valideren van uw JSON-gegevens.
Voorbeeld:
{
"description": "Een persoon",
"type": "object",
"eigendommen":
{
"naam":
{
"type": "string"
},
"leeftijd":
{
"type": "geheel getal",
"maximum": 125
}
}
}
U kunt documentatie verstrekken door het kenmerk description schema te gebruiken.
|
Als u Jackson als uw JSON-parser gebruikt, kunt u dit als volgt inschakelen om opmerkingen toe te staan:
ObjectMapper mapper = new ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, true);
Dan kun je opmerkingen hebben zoals deze:
{
key: "waarde" // Commentaar
}
En u kunt ook opmerkingen hebben die beginnen met # door in te stellen:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, true);
Maar over het algemeen (zoals eerder beantwoord) laat de specificatie geen opmerkingen toe.
|
Dit is wat ik heb gevonden in de Google Firebase-documentatie waarmee je opmerkingen in JSON kunt plaatsen:
{
"//": "Sommige browsers gebruiken dit om pushmeldingen in te schakelen.",
"//": "Het is hetzelfde voor alle projecten, dit is niet de afzender-ID van uw project",
"gcm_sender_id": "1234567890"
}
|
NEE. Vroeger ondersteunde JSON opmerkingen, maar deze werden misbruikt en uit de standaard verwijderd.
Van de maker van JSON:
Ik heb opmerkingen uit JSON verwijderd omdat ik zag dat mensen ze gebruikten om ontledingsrichtlijnen vast te houden, een praktijk die de interoperabiliteit zou hebben vernietigd. Ik weet dat het gebrek aan opmerkingen sommige mensen verdrietig maakt, maar dat zou niet moeten. - Douglas Crockford, 2012
De officiële JSON-site is op JSON.org. JSON wordt door ECMA International als standaard gedefinieerd. Er is altijd een verzoekschriftprocedure om normen te laten herzien. Het is om verschillende redenen onwaarschijnlijk dat annotaties worden toegevoegd aan de JSON-standaard.
JSON by design is een gemakkelijk reverse-engineered (door mensen geparseerd) alternatief voor XML. Het is zelfs zo vereenvoudigd dat annotaties niet nodig zijn. Het is niet eens een opmaaktaal. Het doel is stabiliteit en interoperabiliteit.
Iedereen die de "heeft-a" -relatie van objectoriëntatie begrijpt, kan elke JSON-structuur begrijpen - dat is het hele punt. Het is gewoon een gerichte acyclische grafiek (DAG) met knooppunt-tags (sleutel / waarde-paren), wat een bijna universele gegevensstructuur is.
Deze enige vereiste annotatie kan zijn "// Dit zijn DAG-tags". De sleutelnamen kunnen zo informatief zijn als nodig is, waardoor willekeurige semantische ariteit mogelijk is.
Elk platform kan JSON parseren met slechts een paar regels code. XML vereist complexe OO-bibliotheken die op veel platforms niet levensvatbaar zijn.
Annotaties zouden JSON alleen maar minder interoperabel maken. Er is gewoon niets anders toe te voegen, tenzij u echt een markup language (XML) nodig hebt, en het maakt niet uit of uw persistente gegevens gemakkelijk kunnen worden geparseerd.
MAAR zoals de maker van JSON ook opmerkte, is er altijd JS-pijplijnondersteuning geweest voor opmerkingen:
Ga je gang en voeg alle opmerkingen in die je leuk vindt.
Leid het vervolgens door JSMin voordat u het aan uw JSON-parser overhandigt. - Douglas Crockford, 2012
|
Als uw tekstbestand, dat een JSON-string is, door een programma wordt gelezen, hoe moeilijk zou het dan zijn om opmerkingen in C- of C ++ -stijl te verwijderen voordat u het gebruikt?
Antwoord: het zou een one liner zijn. Als u dat doet, kunnen JSON-bestanden worden gebruikt als configuratiebestanden.
|
Als u de Newtonsoft.Json-bibliotheek met ASP.NET gebruikt om te lezen / deserialiseren, kunt u opmerkingen in de JSON-inhoud gebruiken:
// "naam": "string"
// "id": int
of
/* Dit is een
commentaar voorbeeld * /
PS: opmerkingen van één regel worden alleen ondersteund met 6+ versies van Newtonsoft Json.
Extra opmerking voor mensen die niet out of the box kunnen denken: ik gebruik het JSON-formaat voor basisinstellingen in een ASP.NET-webtoepassing die ik heb gemaakt. Ik lees het bestand, converteer het naar het instellingenobject met de Newtonsoft-bibliotheek en gebruik het indien nodig.
Ik schrijf liever opmerkingen over elke individuele instelling in het JSON-bestand zelf, en ik geef echt niet om de integriteit van het JSON-formaat, zolang de bibliotheek die ik gebruik er maar goed in is.
Ik denk dat dit een 'gemakkelijker te gebruiken / begrijpelijke' manier is dan een apart 'settings.README'-bestand te maken en de instellingen erin uit te leggen.
Als u een probleem heeft met dit soort gebruik; sorry, de geest is uit de lamp. Mensen zouden andere toepassingen vindenJSON-indeling, en u kunt er niets aan doen.
|
Het idee achter JSON is om eenvoudige gegevensuitwisseling tussen applicaties mogelijk te maken. Deze zijn meestal webgebaseerd en de taal is JavaScript.
Het staat niet echt commentaar als zodanig toe, maar het doorgeven van een commentaar als een van de naam / waarde-paren in de gegevens zou zeker werken, hoewel die gegevens duidelijk zouden moeten worden genegeerd of specifiek behandeld door de parseercode.
Dat gezegd hebbende, het is niet de bedoeling dat het JSON-bestand opmerkingen in de traditionele zin bevat. Het zouden alleen de gegevens moeten zijn.
Bekijk de JSON-website voor meer details.
|
JSON ondersteunt native geen opmerkingen, maar je kunt je eigen decoder of op zijn minst preprocessor maken om opmerkingen te verwijderen, dat is prima (zolang je opmerkingen negeert en ze niet gebruikt om te begeleiden hoe je toepassing de JSON-gegevens moet verwerken ).
JSON heeft geen opmerkingen. Een JSON-encoder MAG GEEN opmerkingen uitvoeren.
Een JSON-decoder KAN opmerkingen accepteren en negeren.
Opmerkingen mogen nooit worden gebruikt om iets zinvols over te brengen. Dat is
waar JSON voor is.
Zie: Douglas Crockford, auteur van JSON-spec.
|
Ik kom dit net tegen voor configuratiebestanden. Ik wil geen XML (uitgebreid, grafisch, lelijk, moeilijk te lezen) of "ini" -formaat (geen hiërarchie, geen echte standaard, enz.) Of Java "Eigenschappen" -formaat (zoals .ini) gebruiken.
JSON kan alles doen wat ze kunnen, maar het is veel minder uitgebreid en beter leesbaar voor mensen - en parsers zijn gemakkelijk en alomtegenwoordig in veel talen. Het is gewoon een gegevensboom. Maar out-of-band opmerkingen zijn vaak een noodzaak om "standaard" configuraties en dergelijke te documenteren. Configuraties mogen nooit "volledige documenten" zijn, maar bomen met opgeslagen gegevens die indien nodig door mensen kunnen worden gelezen.
Ik denk dat je "#": "comment" zou kunnen gebruiken voor "geldige" JSON.
|
Het hangt af van uw JSON-bibliotheek. Json.NET ondersteunt opmerkingen in JavaScript-stijl, / * commment * /.
Zie nog een Stack Overflow-vraag.
|
JSON heeft veel zin voor configuratiebestanden en ander lokaal gebruik, omdat het alomtegenwoordig is en omdat het veel eenvoudiger is dan XML.
Als mensen sterke redenen hebben om geen opmerkingen in JSON te hebben bij het communiceren van gegevens (al dan niet geldig), dan kan JSON mogelijk in tweeën worden gesplitst:
JSON-COM: JSON op de draad, of regels die van toepassing zijn bij het communiceren van JSON-gegevens.
JSON-DOC: JSON-document of JSON in bestanden of lokaal. Regels die een geldig JSON-document definiëren.
JSON-DOC staat commentaar toe, en er kunnen andere kleine verschillen zijn, zoals het omgaan met witruimte. Parsers kunnen gemakkelijk van de ene specificatie naar de andere converteren.
Met betrekking tot de opmerking van Douglas Crockford over deze kwesties (waarnaar wordt verwezen door @Artur Czajka)
Stel dat u JSON gebruikt om configuratiebestanden te bewaren, die u wilt annoteren. Ga je gang en voeg alle opmerkingen in die je leuk vindt. Leid het vervolgens door JSMin voordat u het aan uw JSON-parser overhandigt.
We hebben het over een algemeen probleem met configuratiebestanden (taaloverschrijdend / platform), en hij antwoordt met een JS-specifiek hulpprogramma!
Natuurlijk kan een JSON-specifieke minify in elke taal worden geïmplementeerd,
maar standaardiseer dit zodat het alomtegenwoordig wordt in parsers in alle talen en platforms, zodat mensen hun tijd niet langer verspillen aan het ontbreken van de functie omdat ze er goede use-cases voor hebben, het probleem opzoeken in online forums en mensen laten vertellen dat het een slecht idee is of suggereert dat het eenvoudig is om het verwijderen van opmerkingen uit tekstbestanden te implementeren.
Het andere probleem is de interoperabiliteit. Stel dat u een bibliotheek of API of een ander subsysteem heeft waaraan enkele configuratie- of gegevensbestanden zijn gekoppeld. En dit subsysteem is
toegankelijk zijn vanuit verschillende talen. Vertel het dan maar aan mensen: trouwens
vergeet niet om de opmerkingen uit de JSON-bestanden te verwijderen voordat u ze doorgeeft aan de parser!
|
Als u JSON5 gebruikt, kunt u opmerkingen toevoegen.
JSON5 is een voorgestelde uitbreiding op JSON die tot doel heeft het voor mensen gemakkelijker te maken om met de hand te schrijven en te onderhouden. Het doet dit door enkele minimale syntaxisfuncties rechtstreeks vanuit ECMAScript 5 toe te voegen.
|
Met de Dojo Toolkit JavaScript-toolkit (tenminste vanaf versie 1.4) kunt u opmerkingen opnemen in uw JSON. De opmerkingen kunnen de indeling / * * / hebben. Dojo Toolkit gebruikt de JSON via de aanroep dojo.xhrGet ().
Andere JavaScript-toolkits werken mogelijk op dezelfde manier.
Dit kan handig zijn wanneer u experimenteert met alternatieve gegevensstructuren (of zelfs gegevenslijsten) voordat u een laatste optie kiest.
|
JSON is geen omkaderd protocol. Het is een taalvrij formaat. Het formaat van een opmerking is dus niet gedefinieerd voor JSON.
Zoals veel mensen hebben gesuggereerd, zijn er enkele trucs, bijvoorbeeld dubbele sleutels of een specifieke sleutelcommentaar die u kunt gebruiken. Het is aan u.
|
U kunt opmerkingen hebben in JSONP, maar niet in pure JSON. Ik heb zojuist een uur geprobeerd mijn programma te laten werken met dit voorbeeld van Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Als je de link volgt, zul je zien
? (/ * AAPLhistorische OHLC-gegevens van de Google Finance API * /
[
/ * Mei 2006 * /
[1147651200000,67,79],
[1147737600000,64,98],
...
[1368057600000.456,77],
[1368144000000,452,97]
]);
Omdat ik een soortgelijk bestand in mijn lokale map had, waren er geen problemen met het Same-origin-beleid, dus besloot ik pure JSON te gebruiken ... en natuurlijk faalde $ .getJSON geruisloos vanwege de opmerkingen.
Uiteindelijk stuurde ik zojuist een handmatig HTTP-verzoek naar het bovenstaande adres en realiseerde me dat het inhoudstype text / javascript was, omdat JSONP puur JavaScript retourneert. In dit geval is commentaar toegestaan. Maar mijn applicatie retourneerde content-type application / json, dus ik moest de opmerkingen verwijderen.
|
Dit is een "kunt u" -vraag. En hier is een "ja" antwoord.
Nee, u mag geen dubbele objectleden gebruiken om zijkanaalgegevens in een JSON-codering te stoppen. (Zie "De namen binnen een object MOETEN uniek zijn" in de RFC).
En ja, je zou opmerkingen rond de JSON kunnen invoegen, die je zou kunnen analyseren.
Maar als u een manier wilt om willekeurige zijkanaalgegevens in te voegen en te extraheren naar een geldige JSON, dan is hier een antwoord. We profiteren van de niet-unieke weergave van gegevens in een JSON-codering. Dit is toegestaan * in sectie twee van de RFC onder "witruimte is toegestaan voor of na een van de zes structurele tekens".
* De RFC vermeldt alleen "witruimte is toegestaan voor of na een van de zes structurele tekens", zonder expliciet de strings, getallen, "false", "true" en "null" te noemen. Deze weglating wordt in ALLE implementaties genegeerd.
Maak eerst uw JSON canoniek door deze te verkleinen:
$ jsonMin = json_encode (json_decode ($ json));
Codeer vervolgens uw commentaar in binair:
$ hex = uitpakken ('H *', $ comment);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Zet dan je binaire bestand vast:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Hier is je output:
$ jsonWithComment = $ steg. $ jsonMin;
|
Disclaimer: dit is dom
Er is eigenlijk een manier om opmerkingen toe te voegen en binnen de specificatie te blijven (geen extra parser nodig). Het zal echter niet resulteren in voor mensen leesbare opmerkingen zonder enige vorm van parsering.
U kunt het volgende misbruiken:
Onbeduidende witruimte is toegestaan voor of na een token.
Witruimte is een reeks van een of meer van de volgende codes
punten: tekentabel (U + 0009), line feed (U + 000A), wagen
return (U + 000D) en spatie (U + 0020).
Op een hacky manier kun je dit misbruiken om een opmerking toe te voegen. Bijvoorbeeld: begin en eindig je opmerking met een tab. Codeer de opmerking in base3 en gebruik de andere witruimtetekens om ze weer te geven. Bijvoorbeeld.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(hallo basis drie in ASCII) Maar gebruik in plaats van 0 spatie, gebruik voor 1 regelinvoer en voor 2 regelterugloop.
Dit zal je gewoon een hoop onleesbare witruimte achterlaten (tenzij je een IDE-plug-in maakt om het meteen te coderen / decoderen).
Ik heb dit zelfs nooit geprobeerd, om voor de hand liggende redenen en jij ook niet.
|
JSON staat per se geen opmerkingen toe. De redenering is volkomen dwaas, omdat je JSON zelf kunt gebruiken om opmerkingen te maken, waardoor de redenering volledig wordt overbodig en de gegevensruimte van de parser zonder enige goede reden wordt geladen voor precies hetzelfde resultaat en potentiële problemen, zoals ze zijn: een JSON bestand met opmerkingen.
Als u opmerkingen probeert in te voeren (bijvoorbeeld met // of / * * / of #), zullen sommige parsers mislukken omdat dit strikt genomen niet
binnen de JSON-specificatie. Dus dat zou je nooit moeten doen.
Hier, bijvoorbeeld, waar mijn beeldmanipulatiesysteem beeldnotaties heeft opgeslagen en wat basis geformatteerde (commentaar) informatie die daarop betrekking heeft (onderaan):
{
"Notaties": [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Ellips",
"omvangX": 356,
"omvangY": 294,
"dekking": 0,5,
"text": "Elliptisch gebied bovenaan",
"textX": 333,
"textY": 265,
"title": "Notatie 1"
},
{
"anchorX": 87,
"anchorY": 385,
"areaMode": "Rechthoek",
"omvangX": 109,
"omvangY": 412,
"dekking": 0,5,
"text": "Rechtstreeks \ niet onder",
"textX": 98,
"textY": 385,
"title": "Notatie 2"
},
{
"anchorX": 69,
"anchorY": 104,
"areaMode": "Polygoon",
"omvangX": 102,
"omvangY": 136,
"dekking": 0,5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"i": 3,
"x": 83,
"y": 104
}
],
"text": "Eenvoudige veelhoek",
"textX": 85,
"textY": 104,
"title": "Notatie 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "JSON-afbeeldingsnotatiegegevens:",
"c02": "-------------------------",
"c03": "",
"c04": "Deze gegevens bevatten afbeeldingsnotaties en gerelateerd gebied",
"c05": "selectie-informatie die een middel biedt voor een",
"c06": "afbeeldingengalerij om notaties met elliptisch weer te geven,",
"c07": "rechthoekige, veelhoekige of vrije handaanduidingen",
"c08": "over een afbeelding die aan een galerijbezoeker wordt getoond.",
"c09": "",
"c10": "X- en Y-posities zijn allemaal in beeldruimte. De afbeelding",
"c11": "resolutie wordt gegeven als imageXW en imageYW, die",
"c12": "u gebruikt om de notatiegebieden naar hun juiste schaal te schalen",
"c13": "locaties en formaten voor uw weergave van de afbeelding,",
"c14": "ongeacht de schaal.",
"c15": "",
"c16": "Voor ellipsen is anker het midden van de ellips,",
"c17": "en de extents zijn respectievelijk de X- en Y-stralen.",
"c18": "",
"c19": "Voor rechthoeken is het anker linksboven en de",
"c20": "extents zijn rechtsonder.",
"c21": "",
"c22": "Voor de gebiedsmodi Freehand en Polygoon, de pointList",
"c23": "bevat een reeks genummerde XY-punten. Als het gebied",
"c24": "is gesloten, het laatste punt is hetzelfde als de",
"c25": "ten eerste, dus u hoeft zich alleen maar bezig te houden met tekenen",
"c26": "lijnen tussen de punten in de lijst. Anker en omvang",
"c27": "staan linksboven en rechtsonder van de aangegeven",
"c28": "region, en kan worden gebruikt als een simplistische rechthoek",
"c29": "detecteren voor de muisaanwijzerpositie boven deze typen",
"c30": "van gebieden.",
"c31": "",
"c32": "De textx- en texty-posities bieden basispositionering",
"c33": "informatie om u te helpen de tekstinformatie te vinden",
"c34": "op een redelijke locatie in verband met het gebied",
"c35": "indicatie.",
"c36": "",
"c37": "Ondoorzichtigheid is een waarde tussen 0 en 1, waarbij .5 staat voor",
"c38": "een ondoorzichtige achtergrond van 50% en 1,0 staat voor een volledig ondoorzichtige achtergrond",
"c39": "backdrop. Aanbeveling is dat regio's worden getekend",
"c40": "alleen als de gebruiker de aanwijzer over de afbeelding beweegt,",
"c41": "en dat de tekst die bij de regio's hoort, wordt getekend",
"c42": "alleen als de gebruiker de aanwijzer boven de aangegeven",
"c43": "regio."
}
}
|
We gebruiken strip-json-comments voor ons project. Het ondersteunt zoiets als:
/ *
* Omschrijving
* /
{
// regenbogen
"eenhoorn": / * ❤ * / "cake"
}
Gewoon npm install --save strip-json-comments om het te installeren en te gebruiken zoals:
var strip_json_comments = vereisen ('strip-json-comments')
var json = '{/ * regenbogen * / "unicorn": "cake"}';
JSON.parse (strip_json_comments (json));
// => {eenhoorn: 'cake'}
|
In mijn geval moet ik opmerkingen gebruiken voor foutopsporingsdoeleinden vlak voor de uitvoer van de JSON-structuur. Dus besloot ik om foutopsporingsinformatie in de HTTP-header te gebruiken om te voorkomen dat de client kapot ging:
header ("My-Json-Comment: Ja, ik weet dat het een tijdelijke oplossing is ;-)");
|
Om een JSON-item in delen te knippen, voeg ik "dummy comment" -regels toe:
{
"#############################" : "Deel 1",
"data1": "waarde1",
"data2": "waarde2",
"#############################" : "Deel 2",
"data4": "waarde3",
"data3": "waarde4"
}
|
1
2
De volgende
Zeer actieve vraag. Verdien 10 reputatie om deze vraag te beantwoorden. De reputatievereiste helpt deze vraag te beschermen tegen spam en niet-beantwoording.
Niet het antwoord waar je naar zoekt? Blader door andere vragen met de tag json-opmerkingen of stel uw eigen vraag.